1. Field of the Invention
The present invention relates to a method for using a shared library in a microprocessor having a function for supporting the multi-task program execution environment and program and data encryption/decryption function so as to realize the protection of secrecy and the prevention of alteration for the execution codes of the programs and the processing target data.
2. Description of the Related Art
In the computer systems of recent years, the open system constructed by combining hardware and software of various makers has been widespread, as in the case of PCs. In the open system, the information on hardware and system program (or operating system (OS)) is publicly disclosed so that it is in principle possible for an end user to modify or alter the system program according to this information
In the application program to be executed in such an environment, it is difficult for a provider of the application program to completely protect the program from the analysis and the alteration. The application program is operated under the management of the OS, so that there is no way of escaping from the attack when the OS itself is altered and used as means for attacking.
For this reason, there is a method to encrypt the application program in advance, in order to prevent the analysis of the application program to be operated in the open system. When the program is encrypted, not only the analysis becomes difficult but also the prediction of the operation in the case where the program is altered also becomes difficult so that it is also effective for the prevention of the alteration. However, the encrypted application program cannot be executed as it is by the existing computer, so that there is a need for a microprocessor which can execute the program while decrypting the program. This microprocessor must protect the secrecy of the program on the presumption that the OS may carry out hostile operations against the application program.
A microprocessor that can satisfy these requirements includes one proposed in commonly assigned co-pending U.S. patent application Ser. Nos. 09/781,158 and 09/781,284, and one disclosed in Lie et al., “Architectural Support for Copy and Tamper Resistant Software”, Proceedings of ASPLOS-IX 2000, November, 2000. These proposed microprocessors have a function for encrypting not just programs but also information and data to be handled by the programs as a protection against the analysis and the alteration. They also provides the multi-task program execution environment for executing a plurality of programs simultaneously in a pseudo-parallel manner. In the following such a microprocessor will be referred to as a tamper resistant microprocessor.
In the conventionally proposed tamper resistant microprocessor, it is assumed that the application program is operated singly and all the necessary processing can be realized by its execution code alone. A method for sharing the data region in order to realize the cooperative operations by a plurality of programs has also been proposed in commonly assigned co-pending U.S. patent application Ser. No. 10/028,794. However, even in this case, the programs that are carrying out the cooperative operations are mutually independent individual programs.
On the other hand, the current OS often utilizes the shared library. Here, the library is a collection of sub-programs such as a sub-routine (a group of instructions which have a certain function in the program) which constitute the program. The programmer of the application program can rely on the sub-programs provided in the library for a part of functions of the application program, instead of implementing in the application program all the functions necessary for the operation of the application program. The library and the application program can be separately developed and then freely combined later on for use, so that they can make the software development more efficient.
The classic library is linked to the application program at a time of producing the application program, and the sub-programs of the library are distributed integrally with the application program. On the other hand, the shared library that is widely in use today is distributed as a separate file independent from the application program.
In the case of the shared library, the link to the application program is made when the user actually executes the program. Also, this linking operation is carried out with respect to an image of the application program on memory, rather than with respect to the executable object file of the application program. Once the linking between the application program and the shared library is carried out, it becomes possible to use the sub-programs of the shared library by freely calling them up from the application program, similarly as the sub-programs of an ordinary library.
One of the advantages for using the shared library is that the necessary memory region can be reduced. A total size of one application program and the shared library to be used by that application program is always larger than the size in the case of not utilizing the shared library. However, when there are a plurality of application programs which use the same shared library, it suffices to have one copy of the shared library so that the necessary memory region can be reduced overall. This reduction of the necessary memory region is effective for both the secondary memory (external memory device such as disks) on which the distributed file of the application program is stored and the main memory of the computer on which the application program is stored at a time of its execution.
Among the shared libraries, those known as a dynamic link type (dynamic link shared libraries) have a feature that the shared library can be changed without changing the application program. When the dynamic link shared library is used, it is possible to change a part of the functions of the application program or correct errors in the application program, without changing the application program itself, by replacing one shared library with another shared library. Also, in the case where the application program searches the available shared library after the execution starts and loads the shared library found by the search, it is possible to add functions to the application program without changing the application program itself, by separately providing the shared library alone. The shared library designed to be used in this manner is often referred to as a plug-in.
So far there has been no proposition for an architecture that can enable the use of the shared library on the tamper resistant microprocessor described above.
In order to implement the shared library on the tamper resistant microprocessor, there is a need to satisfy the following requirements. Namely, it is required that the routines of the shared library can be called up from the application program, and that data may be passed to the routine at a time of calling up the routine, and data of the processing result can be returned to the called source when the processing returns from the routine.
In addition, in order to maintain the protection function for data, etc. that is provided by the tamper resistant microprocessor effectively functional, there is a need to protect the secrecy of the information to be exchanged between the application program and the shared library from the OS, etc. In the case of exchanging data to be kept secret at a time of calling up the routine, there is a need to authenticate the correspondent in order to check whether it is a trustworthy correspondent or not (Whether the shared library has been replaced with another malicious shared library by the OS, etc. or not). There is also a need to prevent a secret substitution of another routine into the call up target routine after this authentication is finished. In the case where the shared library are to be used simultaneously from a plurality of application programs, the leakage of a secret of one program to another program by the shared library must be prevented.
Also, the shared library must be usable from arbitrary application. In other words, if the shared library is usable only from a specific application program as a result of the authentication, it would be insufficient as the shared library because its use is limited. On the other hand, from a viewpoint of the application program that uses the shared library, it is preferable to be able to confirm that the shared library will not leak data to the others, before giving data to be kept secret to the shared library.
For these reasons, there is a need to provide a mechanism by which the application program can authenticate the shared library.
The operation of the shared library is to receive data from the application program, apply some processing on the data, and return the processing result to the application program. Here, the data received from the application program and the processing result should not be leaked to the third party other than the application program and the shared library. Namely, not only the data exchange must be carried out by applying the encryption, but there is also a need to check that the program to which the processing result corresponding to the received data is going to be returned is the same application program which originally provided the data.
Also, anyone can write an application program that uses the shared library, so that there is a possibility of being used from a malicious application program. Even in such a case, it must be capable of protecting the internal operation of the shared library from the analysis. In other words, it must be capable of preventing the reading of the execution code of the shared library by the application program and the peeping of the intermediate data during the processing of the data given to the shared library by the application program.